[Chapter 33] Database Macros
Author: Bryan Costales & Eric Allman
Date: 1999-01-06T20:21:37Z

#

| Chapter 33 |

# 33. Database Macros

Contents:
Enable at Compile Time
Create Files with makemap
The K Configuration Command
Use Maps with $( and $) in Rules
The User Database
Database Maps and m4
Pitfalls
Alphabetized Reference

Database macros are special forms of defined macros. When used with certain special operators, they can cause rules to access information in external files. Database macros offer these advantages:

- Information may be easily changed without having to kill and restart sendmail, because database information is external to the configuration file.

- The sendmail program starts up faster, because only the location of the information is stored at startup, rather than the information itself.

- Rules are more versatile because database information can be used in the RHS side of rules. Class macros are still of use in the LHS.

To fully appreciate sendmail databases, consider the only alternative, the `F` configuration command. For example, mail that is sent by using UUCP is a typical application that requires lists of information:

>     FU /etc/mail/uuhosts

Here, the external file /etc/mail/uuhosts contains a list of UUCP hosts connected to the local machine. If the list rarely changes, the `F` command is appropriate. On the other hand, if the list is volatile and changes often, the `F` command has drawbacks. The file /etc/mail/uuhosts is read only when the configuration file is processed. Any change to that file is ignored by a running sendmail (such as the daemon). To make the change effective, the daemon needs to be killed and restarted. [1]

> [1] If you're running an old sendmail version with a freeze file, that file also will need to be recreated.

In such volatile situations, storing UUCP information in a database is preferred. A change to a database is immediately available to the running daemon, eliminating the need to kill and restart.

V8 sendmail is designed to rewrite addresses on the basis of information looked up in external databases or in its internal symbol table. It can use a wide variety of database forms, ranging from ndbm(3) files (see Section 33.8.3, dbm) to Hesiod network maps (see Section 33.8.6, hesiod). The `K` configuration command (see Section 33.3, "The K Configuration Command") is used to declare the name, location, and other parameters of databases or to modify use of its symbol table. The `$(` and `$)` database operators (see Section 33.4, "Use Maps with $( and $) in Rules") are used in the RHS of rules to access and utilize that information.

## 33.1 Enable at Compile Time

Vendors that provide V8 sendmail in precompiled form may or may not provide access to all the types of databases that V8 sendmail supports. If your online documentation lacks this information, you can run strings(1) on sendmail to discover what it supports:

>     % strings /usr/lib/sendmail | grep map_open

>     ndbm_map_open(%s, %s, %d)
>     hash_map_open(%s, %s, %d)
>     nis_map_open(%s, %s)
>     text_map_open(%s, %s, %d)
>     text_map_open: file name required
>     text_map_open(%s): file name must be fully qualified
>     text_map_open(%s): can not stat %s
>     text_map_open(%s): %s is not a file
>     text_map_open(%s): -k should specify a number, not %s
>     text_map_open(%s): -v should specify a number, not %s
>     text_map_open(%s): delimiter = %c
>     stab_map_open(%s, %s)
>     impl_map_open(%s, %s, %d)
>     user_map_open(%s)
>     switch_map_open(%s, %s, %d)

In this implementation of sendmail, NDBM (the `ndbm_map_open`) and Berkeley DB (the `hash_map_open`) type database files are available. Sun style NIS maps (the `nis_map_open`) are also available. The others (`text`, `stab`, `impl`, `user`, and `switch`) are always automatically included. Note that `hesiod` and `nisplus` maps are not supported by this particular sendmail binary.

If you download and compile sendmail yourself, you may include any supported databases. Support is declared on the DBMDEF= line in the appropriate Makefile for your system. Possible definitions for DBMDEF= are shown in Table 33.1.

Table 33.1: DBMDEF Definitions in Makefile
Definition |  | Database Support Included
--- | --- | ---
-DHESIOD | Section 33.8.6 | hesiod(3) aliases only
-DLDAPMAP | Section 33.8.9, ldapx | ldap(3) white pages
-DNDBM | Section 33.8.3 | ndbm(3) database files
-DNEWDB | Section 33.8.1, btree | Berkeley db(3) database files
-DNIS | Section 33.8.11, nis | Sun NIS network databases
-DNISPLUS | Section 33.8.12, nisplus | Sun NIS+ network databases
-DNETINFO | Section 33.8.10, netinfo | NeXT netinfo(3) aliases only

For example, the Makefile.ULTRIX file might include this line:

>     DBMDEF= -DNDBM -DNEWDB -DNIS

which includes support for ndbm(3), db(3), and nis(3) databases, [2] whereas the Makefile.SunOS.5.x file might include the following:

> [2] If you declare support for both NDBM and NEWDB, be sure to remove ndbm.h and ndbm.o from the NEWDB distribution. Failure to remove them will confuse sendmail, causing it to fail in ugly ways.

>     DBMDEF= -DNDBM -DNIS -DNISPLUS

which excludes db(3) support but includes nisplus(3) support.

If you omit all database support (by undefining DBMDEF, for example, or not supplying support indications after the equal sign), sendmail will be unable to maintain its aliases in database format. Also, any attempt to rebuild the aliases database (with newalias or with `-bi`) will fail with the following error message:

>     Cannot rebuild aliases: no database format defined
>     Cannot create database for alias file /etc/aliases: No such device

Note that if you add new map types, you may have to also add libraries to the LIBS= line in your Makefile.

32.5 Alphabetized Reference |  | 33.2 Create Files with makemap